As known, current communication networks, such as IP (internet Protocol) networks, make use of the Multi-Protocol Label Switching (MPLS) for carrying data traffic flows between the nodes of the network. Data traffic flows are made of packets that are generated at a source node. According to the MPLS, each packet is associated to a “label”. The packets are then routed towards a destination node on the basis of their labels.
In particular, the path followed by a packet from a source node to a destination node within a MPLS network is called a Label Switched Path (LSP). It is determined by the MPLS control plane of the network before transmitting the packets and typically comprises one or more intermediate nodes between the source node and the destination node. At each intermediate node, the packet is switched to the next intermediate node of the determined path according to the value of the label it carries. Prior to sending the packet, the intermediate node replaces the label with a new value that shall be read by the next intermediate node for performing its own switching operation (this operation is known as “label swapping”).
The MPLS control plane has been extended in order to be used to create label switched path also over non IP networks, such as SDH (Synchronous Digital Hierarchy) or WDM (Wavelength Division Multiplexing) networks. In this form, MPLS control plane is known as Generalized MPLS or GMPLS control plane.
A profile of the MPLS data plane, termed MPLS-TP (MPLS Transport Profile), has also been defined for deploying MPLS packet switching within transport networks.
Traffic engineering (TE) is a method which is typically used in packet networks for improving the routing of the packets and the usage of network resources (e.g. links, devices, interfaces, etc.). It consists in providing additional information to the nodes related to resource usage and resource availability. Moreover, it allows the routing operation to take into account the Quality of Service (QoS) requirements of the data traffic flows transported by the network. For instance, traffic engineering provides information about underused and overused resources and the available bandwidth along the network links. Traffic engineering allows data packets to be routed so that usage of resources is balanced and congestions are avoided, while guaranteeing that the QoS is maintained. MPLS technology has been extended to incorporate TE functionalities and networks implementing such extended version of MPLS are usually referred to as “MPLS-TE networks”.
In the following, the expression “MPLS based network” or simply “MPLS network” will be used to refer indifferently to an MPLS, MPLS-TP or GMPLS network, and also to refer to any one of these networks implementing TE functions.
As known, the set up of an LSP requires coordinated implementation of a routing protocol and a signalling protocol.
The routing protocol supports the advertisement of network topology information and available resource information between the nodes of the network. Known MPLS routing protocols include link state routing protocols, such as the Open Shortest Path First (OSPF) protocol, and in particular the Open Shortest Path First protocol with extensions to support traffic engineering functions (OSPF-TE). The OSPF-TE protocol is defined in the Requests for Comments RFC3630 (September 2003), RFC4202 (October 2005) and RFC4203 (October 2005). In particular, each node maintains a link state database with the current network topology and changes occurring in network topology are distributed through flooding. According to the OSPF-TE protocol, advertisements are flooded among the nodes of the network so as to distribute information on the network topology and also on the properties of the traffic engineering (TE) links comprised within the network. According to RFC4202, a TE link is a “logical” link that has TE properties. The link is logical in a sense that it represents a way to group/map the information about certain physical resources (and their properties) that interconnect the nodes of the network into the information that is used by the MPLS routing protocol, for the purpose of path computation, and by the MPLS signalling protocol. In particular, a TE link may result from the “logical” grouping of one or more physical links between two or more nodes of the network.
The OSPF-TE protocol provides for advertising the properties of a link or a TE link such as the available bandwidth, the switching capabilities, the type of the link and so on in a dedicated link state advertisement (LSA). Moreover, the OSPF-TE protocol provides for collecting the information on TE links into a TE link state database. The LSA related to a link or TE link is originated by an end node of the link and comprises a payload in turn comprising a link TLV (i.e. a triplet Type/Length/Value) describing the link. The link TLV in turn comprises a set of sub-TLVs containing, for instance, the link type (i.e. point-to-point link or multi-access link), the link ID (i.e. the identifier of the other end node of the link) and the IP addresses of the local interfaces. Moreover, the link TLV may comprise a further sub-TLV, the Interface Switching Capability Descriptor (ISCD) TLV, which describes the switching capabilities (e.g. the capability of switching packets on a packet-by-packet basis according to the carried label) of the interface(s) through which the link is connected to the node generating the LSA.
The signalling protocol supports tasks such as exchanging control information among nodes, distributing labels, and reserving resources along the path. Known signalling protocols for the MPLS control plane include the Resource Reservation Protocol (RSVP), and, in particular the Resource Reservation Protocol with extensions to support traffic engineering functions (RSVP-TE). The RSVP protocol is defined in the IETF's Requests for Comments RFC2205 (September 1997) and RFC2210 (September 1997). According to such protocol, the source node generating a data traffic flow sends a path message that is transmitted to the first intermediate node and then forwarded to the other intermediate nodes along the label switched path whose route is selected based on the information distributed by the routing protocol. As known (see document RFC2210, section 3.1), the path message contains some data objects comprising, inter alia, a sender_template object comprising the IP address of the source node, a sender_tspec object comprising the traffic attributes of the source node's data traffic flow and further comprising the bandwidth of the label switched path, and an adspec object containing advertising data. The destination node, at the reception of the path message, sends a reservation message to the source node along the reverse path, which triggers each intermediate node to reserve the resources needed to set up the label switched path.
As known, in a MPLS network, OAM (Operation, Administration and Management) functions are defined which allows, inter alia, monitoring the presence of failures along a label switched path at an end node of the path. In particular, this monitoring function may be performed via the periodic transmission of a continuity check (CC) packet towards the opposite end node of the path (see document RFC6371, September 2011). If the CC packet is not received within a certain number of consecutive transmission periods (typically three) the monitored LSP is declared in failure.
A known OAM protocol configured to detect the presence of failures along a label switched path is the Bidirectional Forwarding Detection (BFD) protocol. The BFD protocol has been extended in order to support the emission of CC packets and this extension is defined in IETF's Request for Comments RFC 6428 (November 2011). According to this exemplary OAM protocol, the end nodes of the path start a monitoring session by negotiating the rate of transmission of the CC packets, according to their respective available rate of transmission, and then the CC packets are sent at the negotiated rate of transmission so that a failure may be detected after three transmission periods.
Once a failure is detected on a label switched path, it is further known to implement a protection mechanism (i.e. re-routing the traffic on a pre-established alternative protection path), a restoration mechanism (i.e. re-routing the traffic on a new path dynamically calculated as soon as the failure is detected) or a protection and restoration combined (PRC) mechanism for recovering from the failure. In particular, the PRC mechanisms allows recovering from dual failures, i.e. failures on both the working and protection paths by dynamically calculating another protection path. Typically, the time for switching from the working path to the protection path, and, in case of a further failure on the protection path, from the failed protection path to the protection path which is dynamically established, shall be lower than a threshold which depends on the required performances and on the service level associated to the traffic to be protected. The switching time required to comply with the service level agreements may be some tens of milliseconds, e.g. less than 50 ms.